The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docx-editor	Ready	Preview, Comment	Jun 21, 2026 1:46pm

All contributors have signed the CLA ✍️ ✅

_{Posted by the CLA bot.}

Greptile Summary

This PR hardens the clipboard HTML paste boundary in packages/core/src/utils/clipboard.ts against three CodeQL-flagged vulnerabilities: XSS via innerHTML, an incomplete multi-character sanitization that could leave a stray <!--, and a polynomial-backtracking regex on comment stripping.

• XSS fix: htmlToRuns now sanitizes pasted HTML through DOMPurify before parsing it into an inert DOMParser document, so nothing is ever written to innerHTML on the live DOM.
• Comment stripping: both regexes in cleanWordHtml are replaced by a single linear-scan function (stripHtmlComments) that handles downlevel conditional comments and drops unterminated openers through end-of-string.
• Test coverage: a new clipboard-html.test.ts validates comment stripping, the onerror payload inertness, and a ReDoS timing guard for the comment-scan path; the <o:>/<w:> lazy-regex paths in cleanWordHtml remain unfixed and are not covered by the timing test.

Confidence Score: 4/5

Safe to merge for the three addressed vulnerabilities; the <o:>/<w:> lazy-regex paths in cleanWordHtml still expose polynomial backtracking on hostile Word HTML and were flagged in the previous review round without being resolved in this iteration.

The XSS and comment-stripping fixes are correct and well-tested. The remaining concern is the two [\s\S]*? patterns for Office namespace tags in cleanWordHtml; they are reachable via the Word HTML code path and were identified in the prior review cycle but are unchanged here. Until those patterns are linearized, a motivated attacker who can get the editor to paste from a crafted Word document can trigger CPU-bound denial of service.

The <o:> and <w:> removal regexes in cleanWordHtml (lines 470–475 of packages/core/src/utils/clipboard.ts) are the remaining risk area.

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Paste event / ClipboardEvent] --> B{isWordHtml?}
    B -- yes --> C[cleanWordHtml\nstripHtmlComments LINEAR SCAN\n+ o:/w: regex strip\n+ mso- style strip]
    B -- no --> D{isEditorHtml?}
    D -- yes --> E{data-docx-editor-content\nattribute present?}
    E -- yes --> F[JSON.parse runs\n← returned directly]
    E -- no --> G[htmlToRuns]
    C --> G
    D -- no --> G
    G --> H[DOMPurify.sanitize\nstrips scripts / event handlers\njavascript: URLs / dangerous tags]
    H --> I[DOMParser.parseFromString\ninert document — no resource fetch\nno script execution]
    I --> J[processNode walk\ntext + formatting only]
    J --> K[Run array returned]

    style C fill:#fffbe6,stroke:#f0ad4e
    style H fill:#e6ffe6,stroke:#28a745
    style I fill:#e6ffe6,stroke:#28a745

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[Paste event / ClipboardEvent] --> B{isWordHtml?}
    B -- yes --> C[cleanWordHtml\nstripHtmlComments LINEAR SCAN\n+ o:/w: regex strip\n+ mso- style strip]
    B -- no --> D{isEditorHtml?}
    D -- yes --> E{data-docx-editor-content\nattribute present?}
    E -- yes --> F[JSON.parse runs\n← returned directly]
    E -- no --> G[htmlToRuns]
    C --> G
    D -- no --> G
    G --> H[DOMPurify.sanitize\nstrips scripts / event handlers\njavascript: URLs / dangerous tags]
    H --> I[DOMParser.parseFromString\ninert document — no resource fetch\nno script execution]
    I --> J[processNode walk\ntext + formatting only]
    J --> K[Run array returned]

    style C fill:#fffbe6,stroke:#f0ad4e
    style H fill:#e6ffe6,stroke:#28a745
    style I fill:#e6ffe6,stroke:#28a745

_{Reviews (3): Last reviewed commit: "fix(core): harden clipboard HTML paste a..." | Re-trigger Greptile}

Greptile triage — the remaining concern from your summary (the <o:>/<w:> lazy-regex ReDoS in cleanWordHtml) is now fixed in e85ef6d9.

The two /<o:[^>]*>[\s\S]*?<\/o:[^>]*>/gi / <w:...> patterns (confirmed quadratic: 20k openers ≈ 228ms, so a ~1MB hostile paste ≈ 20s CPU) are replaced by a linear stripPairedNamespaceTags scanner. It mirrors the lazy first-close-wins semantics exactly (verified equivalent across nested/unterminated/partial-close cases) and runs in ~1ms for 200k openers. Added correctness + ReDoS-guard tests. This closes the last polynomial-backtracking path in the clipboard boundary.

Follow-up: a self-review caught that the new stripPairedNamespaceTags scanner was case-sensitive, whereas the /gi regexes it replaced were case-insensitive — so uppercase <O:P>…</O:P> blocks (rare, but valid in hand-crafted HTML) would no longer be stripped. Fixed in 7f81c6f5: the scanner now locates tag markers in a lowercased copy and slices from the original string, restoring exact /gi parity (verified equivalent across mixed-case cases) while staying linear. Added an uppercase regression test.

🚀 Released in v1.9.0